All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Hartkopp <socketcan@hartkopp.net>
To: Marc Kleine-Budde <mkl@pengutronix.de>,
	"Christopher R. Baker" <cbaker@rec.ri.cmu.edu>,
	linux-can@vger.kernel.org
Subject: Re: Populating netdev::dev_id for udev discrimination
Date: Mon, 10 Mar 2014 08:43:55 +0100	[thread overview]
Message-ID: <531D6D3B.9020900@hartkopp.net> (raw)
In-Reply-To: <531CBB6F.7090803@pengutronix.de>

Hello Christopher,

On 09.03.2014 20:05, Marc Kleine-Budde wrote:
> On 03/08/2014 05:00 PM, Christopher R. Baker wrote:

> You are the first one to address this issue. \o/

I remember we discussed this issue years ago - but it was not really brought
to an end. So I really appreciate Christophers attempt :-)

>> udevadm info gives me the KERNELS=... incantation to match the pci bus
>> address, but there are no other differences in the udev listing for my
>> various CAN ports (at least for my peak_pci device)
>>
>> Digging into the semantics of ATTRS{...}, "dev_id" stood out as having
>> the intention of discriminating between physical ports

I assume dev->if_port has to be assigned to different CAN transceiver types
for a specific CAN controller then ... 

We should keep that in mind if someone comes up with that question.

>> that "share the
>> same link layer" (from netdev.h) or "share the same MAC address" (from
>> various other mailing lists).
>>
>> The following patch assigns the dev_id field to match the channel number
>> on all multi-channel cards

Ok. That looks reasonable (and therefore the patch fits excellent).

As you stated above you can identify the card via the PCI bus address too.

Do you have an idea how to proceed with USB or other devices that bring their
own identification (like a serial number / device id) ??

E.g. the Softing Card provides some serial number through sysfs:

http://lxr.free-electrons.com/source/drivers/net/can/softing/softing_main.c#L719

and e.g. the PEAK USB have a so called "device number" that is currently just
printed in kernel log:

http://lxr.free-electrons.com/source/drivers/net/can/usb/peak_usb/pcan_usb_core.c#L799

Especially to assign USB devices that can be attached in a wild manner each
time a good idea would be needed for udev to identify the adapter.

Do you also have an idea for that? E.g. use the HW MAC address field (we do
not need for CAN) for this kind of "serial number / device id" ??

Regards,
Oliver


  parent reply	other threads:[~2014-03-10  7:44 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-08 16:00 Populating netdev::dev_id for udev discrimination Christopher R. Baker
2014-03-09 19:05 ` Marc Kleine-Budde
2014-03-09 23:32   ` Christopher R. Baker
2014-03-10  7:43   ` Oliver Hartkopp [this message]
2014-03-10 10:46     ` Kurt Van Dijck
2014-03-10 11:01       ` Marc Kleine-Budde
2014-03-10 12:18         ` Oliver Hartkopp
2014-03-11 19:08           ` Marc Kleine-Budde
2014-03-11 19:41             ` Oliver Hartkopp
2014-03-11 19:45               ` Marc Kleine-Budde
2014-03-10 12:18         ` Kurt Van Dijck
2014-03-10 12:15       ` Oliver Hartkopp
2014-03-10 12:52         ` Kurt Van Dijck

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=531D6D3B.9020900@hartkopp.net \
    --to=socketcan@hartkopp.net \
    --cc=cbaker@rec.ri.cmu.edu \
    --cc=linux-can@vger.kernel.org \
    --cc=mkl@pengutronix.de \
    /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.