[lkml]   [2018]   [Oct]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] dvb: Allow MAC addresses to be mapped to stable device names with udev
On Wed, Oct 31, 2018 at 10:36:22AM +0000, David Howells wrote:
> Sean Young <> wrote:
> > > > Devices have a MAC address available, which is printed during boot:
> >
> > Not all dvb devices have a mac address.
> How do I tell? If it's all zeros it's not there?

The mac gets populated through read_mac_address member of
dvb_usb_device_properties. If that's not called (or does not succeed), then
there is no mac address. I think you can safely assume that if it's all 0's
then it was not read.

> > Devices without a mac address shouldn't have a mac_dvb sysfs attribute,
> > I think.
> I'm not sure that's possible within the core infrastructure. It's a class
> attribute set when the class is created; I'm not sure it can be overridden on
> a per-device basis.
> Possibly the file could return "" or "none" in this case?

That's very ugly. Have a look at, for example, rc-core wakeup filters:

> > The dvb type and dvb adapter no is already present in the device name,
> > I'm not sure why this needs duplicating.
> They can be used with ATTR{} in udev rules. I'm not clear that the name can.

See my other email.


> > With this patch, with a usb Hauppauge Nova-T Stick I get:
> > ...
> > ==> /sys/class/dvb/dvb0.demux0/dvb_mac <==
> > 00:00:00:00:00:00
> I can't say why that happens. I don't have access to this hardware. Should
> it have a MAC address there? Is the MAC address getting stored in
> dvbdev->adapter->proposed_mac? Maybe it's not getting read - on the card I
> use it's read by the cx23885 driver... I think... The nova-t-usb2.c file
> doesn't mention proposed_mac.

This is a dib0700-type device (much older).


 \ /
  Last update: 2018-10-31 11:49    [W:0.232 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site